home *** CD-ROM | disk | FTP | other *** search
- The Minutes below should be considered a rough draft - 3/26/92 Megan
-
- The minutes of the Trunk-MIB Working Group
-
- IETF Meeting 3/16/92
- San Diego, CA
-
- Mailing List
-
- o General Discussion: trunk-mib@acc.com
-
- o To subscriber: trunk-mib-request@acc.com
-
- o Archive: saffron.acc.com
-
- Chairs
-
- Fred Baker: fbaker@acc.com
-
- Tracy A. Cox: tacox@sabre.bellcore.com
-
-
- Description and Charter
-
- This working group will consider revisions to the DS1 and DS3 MIBs
- (currently published as Proposed Stds in RFC 1232 and RFC 1233) in
- preparation for their consideration as Draft Standards. Consistent
- with the IETF standards process, the working group is chartered to
- consider only those changes to the DS1 and DS3 MIBs that are based on
- implementation experience or on the need to align with relevant ANSI
- T1M1 standards. In this context, the working group will thoroughly
- document the implementation or alignment rationale for each considered
- change. All changes made by the working group will be consistent with
- the existing SNMP framework and standards --- in particular, those
- provisions of RFC 1155 regarding addition and deprecation of objects in
- standard SNMP MIBs. This working group will be a short-lived activity,
- involving a single meeting, and will conclude its business no later
- than June 1992.
-
-
- Goals and Milestones
-
- o Jan 1992: Distribute draft of proposed revisions to DS1 and DS3
- MIBs together with documentation of supporting implementation
- experience
- o Mar 1992: A one-time only working group meeting as part of IETF
- meeting to review and discuss documents and formulate recommendation
- to IESG
- o Apr 1992: Deposit final document text as Internet Drafts for final
- review by WG membership and consideration by IESG
-
- Agenda
-
- o Get feedback on implementation experience
- o Review RFC1232 and RFC1233 comments
- - Review ds1LineIndex and ds1Index email discussions
- - Review the need for farEndTables
- - Review the need for added configuration information
- - Review new objects: ds1Loopback and ds1AlarmState
- - Removal of CSSs from RFC1233
- - Additional otherCVs count in RFC1233
-
- Feedback
-
- o Add Far End Information -- as optional tables
- o Add more alarm information -- ds1AlarmState
- o Consistency with standards -- updated Terminology section
- o Can't "CSU" MIB be used to manage other DS1 interfaces?
-
-
- Implementation experience was received on RFC1232 and RFC1233. Vendors
- wanted the definitions of the counters to be consistent with T1M1
- standards. The working group agreed that the definitions should be
- updated. However, if the documents should conflict, vendors should
- follow the definitions in the Internet DS1 and DS3 MIBs. Text was
- added to the internet-drafts to reflect this consensus.
-
- Next, the need for far end information was discussed. Vendors
- requested that the far end information received from the DS1 and DS3
- signal be collected in the MIBs. The working group agreed that this
- information should be added as an optional group. The working group
- agreed to structure the MIBs into two groups, the:
-
- -- DS* Near End Group which is mandatory and
- -- DS* Far End Group which is optional.
-
- The Near End Group contains Configuration, Interval, Current, and Total
- tables. The Far End Group contains Configuration, Interval, Current, and Total
- tables.
-
- The working group also reviewed the request from a vendor that more
- configuration information be added to the Configuration Table. The
- working group agreed that this information is important; however, it
- should not be contained on the SNMP agent on the device. The Network
- Management Station should have this information in its database.
- Therefore, the configuration information will not be added to the
- MIBs. This is only true for the Near End Group.
- Since, the configuration information from the Far End is received
- from the incoming signal, the Far End Configuration Table
- does contain this information.
- Therefore, the Far End Group does contain configuration
- information. Only the circuitID object is contained
- in the Near End Configuration
- Table.
-
- Based on vendor requests and consistency with T1M1 standard, some
- objects were deprecated, and new objects were added. This is true for
- both DS1 and DS3 MIBs.
-
- -- ds*Loopback has been deprecated.
-
- -- A new object has been added called ds*NewLoopback,
- which better describes the loopback capabilities of
- a DS* interface on a device.
-
- -- ds*YellowAlarm has been deprecated.
-
- -- ds*RedAlarm has been deprecated.
-
- -- A new object has been added called ds*LineStatus.
- This object better describes the status (e.g., alarm state and
- loopback state) of a DS* interface.
-
- -- Only the ds3IntervalCSSs, ds3CurrentCSSs, and ds3TotalCSSs have
- been deprecated, because these counts are not collected on DS3
- interfaces. They are retained in the DS1 MIB.
-
- -- Additional objects and status are necessary to fully support E1;
- NewBridge will supply details, to be edited into the DS1 MIB.
-
- The internet draft will reflect these changes.
-
- Also, vendors requested that the DS1 and DS3 MIBs be used to manage
- other devices other than CSUs. Therefore, the MIBs are updated to
- reflect this request. The MIB manages DS1/DS3 interfaces.
-
- The following objects have been changed to reflect this request:
-
- -- ds*CSUIndex has been renamed ds*LineIndex. This object
- is the identifier of a DS* Interface on a device. If there is at
- least one ifEntry directly associated with the DS* interface (eg,
- if the DS* interface is used to communicate with the Network
- Layer), it should have the same value as ifIndex. Otherwise, its
- value should exceed ifNumber.
-
- -- ds*Index has been renamed ds*IfIndex. This value for this
- object is equal to the value of ifIndex from the Interfaces
- table of MIB II (RFC 1213). The utility of this object
- is under discussion.
-
- The fractional table was deprecated from the DS1 MIB, because no one
- implemented it or wanted it.
-
- Since the changes to RFC1232 and RFC1233 were on the borderline of
- being "too much", the group agreed to cycle at the Proposed Standard
- status. This implies that the Working Group will have a longer life
- cycle than intended, probably on the order of a year.
-
- New internet drafts reflecting these changes will be sent to
- the trunk-mib mailing list and posted in the internet-drafts
- directories; when consensus is achieved on the mailing list, they will
- be forwarded to the IESG.
-